IRIX Base Documentation 2001 May/SGI IRIX Base Documentation 2001 May.iso/usr/share/catman/p_man/cat5/gp_overflow.z/gp_overflow

Text File | 1998-10-30 | 16.8 KB | 397 lines

ggggpppp____oooovvvveeeerrrrfffflllloooowwww((((5555))))                                                  ggggpppp____oooovvvveeeerrrrfffflllloooowwww((((5555))))



NNNNAAAAMMMMEEEE
     gp_overflow - GP Overflow Errors

TTTTOOOOPPPPIIIICCCC
     This man page is intended to describe the underlying causes of and
     possible solutions for overflowing the gp-relative area in the linker.

TTTThhhheeee SSSSyyyymmmmppppttttoooommmmssss aaaannnndddd aaaa SSSSiiiimmmmpppplllleeee SSSSoooolllluuuuttttiiiioooonnnn
     GP overflow is reported by the linker with one of several error messages:

         GP-relative sections overflow by 0x??? bytes.  Please recompile with
         a smaller -G value.

         GOT overflow: please relink with -multigot.

         GOT unreachable: please relink with -multigot.

     These messages all indicate that the code being linked contains more than
     64KB of GP-relative data area (see the next section), and attempts to
     reference it with a signed 16-bit displacement from the GP register.

     In the past we recommended recompiling with -xgot. Although this
     generally solved the GP overflow problem it created larger, slower
     programs.  We developed ----mmmmuuuullllttttiiiiggggooootttt to create multiple GOTs during linking:
     ----mmmmuuuullllttttiiiiggggooootttt prevents the GOT overflow problem while retaining the more
     efficient GP relative code. -xgot will be dropped in future releases.
     The preferred solution to the problem is to use the ----mmmmuuuullllttttiiiiggggooootttt option to
     _l_d.  At some point ----mmmmuuuullllttttiiiiggggooootttt is likely to become the default default.

     Even with ----mmmmuuuullllttttiiiiggggooootttt one must still avoid having too much GP data:  if the
     ----GGGG value is greater than zero it may be necessary to use a smaller ----GGGG
     value (see below for definitions).

TTTTeeeerrrrmmmmiiiinnnnoooollllooooggggyyyy
     GGGGPPPP   GP (sometimes spelled gp) is a register in the register set of the
          processor.  It used in a consistent way by the software.  The
          register is actually an ordinary integer register (register 28) but
          by software convention it is used only in a stylized way.  The GP-
          area is a region of memory addressable by an offset of the GP
          register. See the section "Underlying Mechanisms" below.

     GGGGOOOOTTTT  To provide Position Independent Code (PIC) which can be relocated
          without modifying the text of the program (or DSO) it is sufficient
          to have a data table with the actual addresses of global data (with
          appropriate code generation and linking support).  This data table
          is constructed by _l_d(1) and is called the Global Offset Table (GOT).
          For a further explanation of what the GOT is, see _d_s_o(5).

     PPPPIIIICCCC  Position Independent Code (PIC) is, as mentioned above, a method of
          code generation which results in code that can be shared by multiple
          users (each program must have its own data space! Code sharing and
          independent data is arranged automatically by the compilation and



                                                                        PPPPaaaaggggeeee 1111






ggggpppp____oooovvvveeeerrrrfffflllloooowwww((((5555))))                                                  ggggpppp____oooovvvveeeerrrrfffflllloooowwww((((5555))))



          run-time systems).  For details on PIC code generation, see the
          _d_s_o(5) (for old-32bit-abi) or the "MIPSpro N32 ABI Handbook" (for
          the new-32bit-abi).

     ----GGGG  nnnn
          This compiler option sets the ----GGGG value, _n.  This compiler option
          affects how much data goes into the "small data" and "small bss" and
          other areas (discussed in the "Underlying Mechanisms" section below
          where _s_h_o_r_t _d_a_t_a _s_e_g_m_e_n_t is defined) ).  The default _n for old-
          32bit-abi compilation (when producing PIC code) is 0.  The default
          for new-32bit-abi and 64bit-abi compilation is 8.  To see the value
          actually in use, use the -_s_h_o_w option on the compilation line and
          check the ----GGGG option actually passed to the compiler passes.

UUUUnnnnddddeeeerrrrllllyyyyiiiinnnngggg MMMMeeeecccchhhhaaaannnniiiissssmmmmssss
     The MIPS instruction set architecture provides instructions for loading
     values from memory, and storing values to memory, which calculate an
     effective address by adding the content of a register to a signed 16-bit
     immediate value (displacement) in the instruction.

     The compilers take advantage of this capability by maintaining various
     frequently-used data objects in a number of small memory sections,
     keeping a pointer to this area of memory in a dedicated register (GP),
     and generating references to those objects as simple load/store
     instructions with signed 16-bit displacements If the total size of these
     memory sections exceeds 64K bytes, the displacements in some of those
     instructions will likely overflow, and the linker reports a GP overflow
     error.

     We will refer to these small GP-relative memory sections collectively as
     the _s_h_o_r_t _d_a_t_a _s_e_g_m_e_n_t below. In general, it is comprised of the Unix
     sections .sdata, .sbss, The data objects placed in the short data segment
     by the compiler and linker include:

     Static data page pointers:
         These are no longer a problem with current code generation and
         linkers.

     GOT pointers:
         References to static data or subroutine addresses in shared code,
         except for those which use page pointers mentioned above, normally
         load an address from the GOT, relative to GP, and use it for the
         access. By default, these address loads assume an offset from GP of
         32KB or less. Using the -multigot linker option tells the linker to
         arrange for as many GOTs as needed in the a.out or DSO (so the fact
         each GOT is limited in size becomes irrelevant).  Using the (now
         deprecated) -xgot compiler option (or -TENV:large_GOT option when
         compiling n32 or 64-bit programs using the MIPSPro compiler) forces
         the compiler to assume full 32-bit offsets from GP, and thereby
         eliminates the restriction that these pointers fit in 64KB.





                                                                        PPPPaaaaggggeeee 2222






ggggpppp____oooovvvveeeerrrrfffflllloooowwww((((5555))))                                                  ggggpppp____oooovvvveeeerrrrfffflllloooowwww((((5555))))



     Small data objects:
         The compiler attempts to place small data objects in a GP-relative
         section (e.g. .sdata or .sbss or .lit4 or .lit8) and to reference
         them directly using a signed 16-bit displacement.  The limit on the
         size of objects treated this way can be changed from the default to nnnn
         bytes by using the -G nnnn option These options must be used
         consistently for all compilations in a given program or linker errors
         will occur. You might get one of these errors:

         "foo" used in bar.o and baz.o has different sizes.

         "foo" used as gp-relative in bar.o and defined otherwise in baz.o.

         "foo" cannot be turned into gp-relative.

          The data objects affected by -G nnnn are numeric literals, addresses
          including those generated by the compiler, all C static variables,
          and (if the "-static"flag was used) FORTRAN local variables.

     Small literal objects:
         The compiler also attempts to place small literal objects (e.g.
         integer constants, floating point constants, addresses) in a GP-
         relative section (e.g. .lit4, .lit8, or .srdata) and to reference
         them directly using a signed 16-bit displacement.  The limit on the
         size of literal objects treated this way can be changed from the
         default to nnnn bytes by using the -G nnnn option.  The -G option must be
         used consistently for all compilations in a given program, or linker
         errors are likely to occur.

     Each of these uses normally has a positive effect on program performance.
     (In fact, performance can often be improved further by increasing the
     sizes of data and literal objects allocated to the short sections.)
     However, if the total size of the four categories exceeds 64KB, the
     linker will report GP overflow errors, and the program must be rebuilt to
     shrink the total size of GP-relative data.

TTTTaaaaiiiilllloooorrrriiiinnnngggg aaaa SSSSoooolllluuuuttttiiiioooonnnn ffffoooorrrr BBBBeeeesssstttt PPPPeeeerrrrffffoooorrrrmmmmaaaannnncccceeee
     The simplest solution is to use the -multigot option.  Finding the best
     solution requires identifying the sizes of the short data section
     components (page pointers, GOT pointers, small data, and small literals),
     and removing only as much as necessary.  With this release this
     information may be obtained from the linker by specifying the flag "-
     gpinfo" directly to ld(1), or by specifying "-Wl,-gpinfo" to cc(1) or
     f77(1).  In other cases, this information may be obtained by specifying
     the "-m -aoutkeep" flags to ld(1) (or -Wl,-m,-aoutkeep to cc(1) or CC(1)
     or f77(1)) and subsequently searching the load map for the desired
     sections.

     Each of these components can be controlled:






                                                                        PPPPaaaaggggeeee 3333






ggggpppp____oooovvvveeeerrrrfffflllloooowwww((((5555))))                                                  ggggpppp____oooovvvveeeerrrrfffflllloooowwww((((5555))))



     Page pointers:
         They are no longer an issue: compiler and linker changes now make the
         the -TENV:no_page_offset option unnecessary.

     GOT pointers:
         These must be GP-relative, but compiling with -multigot enables the
         use of multiple gp regions and the linker will place the short data
         and literal sections closer to an appropriate GP so that they can
         still benefit.

     Small data:
         Compiling with -G nnnn for nnnn smaller than the existing value shrinks
         these sections.  Use ----GGGG 0000 to eliminate all GP-relative small data
         references.  (Note that some small data references will be replaced
         by new GOT pointer references, so the savings might not be as large
         as the original size of the short data sections.)  Recompiling with
         this option requires recompiling the entire program with it.

     Small literals:
         Compiling with -G nnnn for nnnn smaller, shrinks these sections.  Use ----GGGG 0000
         to eliminate all GP-relative small literal references.  (Note that
         some small literal references will be replaced by new GOT pointer
         references, so the savings might not be as large as the original size
         of the short literal sections.)  Recompiling with -G nnnn requires
         recompiling the entire program with it.

     There is another option which may perform better than the above.  The
     main program and each DSO it uses each get their own short data segments.
     Breaking parts of the program into separate DSOs may shrink all of the
     short data segment components enough that the defaults work for some or
     all of the pieces. However, be aware that subprogram calls which cross
     DSO boundaries incur some extra overhead, so this solution is likely to
     help performance only if the division can be made such that such
     crossings are infrequent.

TTTThhhheeee ----xxxxggggooootttt ooooppppttttiiiioooonnnn
     The following is retained to help make clear what the options used with
     -xgot were so you can remove them and use -multigot instead.  Please do
     not use -xgot.  Use -multigot. -multigot requires no recompiling, just
     relinking.  (Any program compiled -xgot should be completely recompiled
     to use -multigot.)  In the future -multigot will be on by default.

     The -xgot rules suggested for the earlier compiler releases were as
     follows:

     For n32 or 64-bit programs, recompile everything in one's program with
     the options:

         ----aaaavvvvooooiiiidddd____ggggpppp____oooovvvveeeerrrrfffflllloooowwww






                                                                        PPPPaaaaggggeeee 4444






ggggpppp____oooovvvveeeerrrrfffflllloooowwww((((5555))))                                                  ggggpppp____oooovvvveeeerrrrfffflllloooowwww((((5555))))



     this eliminates the problem. This flag is a synonym for

         ----GGGG 0000 ----xxxxggggooootttt ----TTTTEEEENNNNVVVV::::nnnnoooo____ppppaaaaggggeeee____ooooffffffffsssseeeetttt

     Programs compiled for the old 32bit abi recompile with

         ----GGGG 0000 ----xxxxggggooootttt

     ----xxxxggggooootttt is likely to have a significant negative impact on the program's
     performance.

BBBBUUUUGGGGSSSS
     _l_d earlier than IRIX 6.2 produced one page pointer per 64KB page of
     static data, whether or not that page is ever referenced. As a result,
     256MB of static data would fill the GP-relative area with page pointers,
     leaving no space for the other GP-relative memory sections. More than
     that would normally cause linker errors unless the -TENV:no_page_offset
     option was used for compilation. The 6.2 and later linkers are much more
     efficient in its data GOT page production making the option
     -TENV:no_page_offset unnecessary.

     A workaround for this problem was to compile all large data blocks from
     files which contain no programs of any kind, and link them into a
     separate data-only dso. Since it contains no code, there will be no
     references to the overflowed GOT. This dso can then be linked against
     when building the main program. Since references to it are always via the
     name of the symbol (or the name of the common in FORTRAN), the data will
     be referenced correctly, but since the data is defined in a dso, space
     will not be allocated in the main program.

     For example, suppose we wanted to define an array of 1,000,000,000
     floating point values. We could then write the following source file in
     C:

         float bigarray[1000000000];

     And subsequently compile it and link it thus:

         cc -c bigarray.c ld -shared bigarray.o -o bigarray.so

     Then we would link the main program thus:

         cc <objects> bigarray.so <libraries>

     To run it we must either install bigarray.so into /usr/lib, or else tell
     the runtime linker rld(1) where to find it. One way of doing this is
     setting the environment variable LD_LIBRARY_PATH to the pathname of the
     directory in which bigarray.so can be found.

     FORTRAN programmers use the source file





                                                                        PPPPaaaaggggeeee 5555






ggggpppp____oooovvvveeeerrrrfffflllloooowwww((((5555))))                                                  ggggpppp____oooovvvveeeerrrrfffflllloooowwww((((5555))))



         BLOCKDATA DUMMY

         COMMON/mycom/bigarray(1000000000)

         END

     Compile it with f77(1), rather than with cc(1), the other steps are the
     same.

SSSSEEEEEEEE AAAALLLLSSSSOOOO
     cc(1), f77(1), ld(1), dso(5), MIPSpro N32 ABI Handbook












































                                                                        PPPPaaaaggggeeee 6666